There are several different approaches that have been tried in the past to solve the problems of data security. The simplest method for data security that provides some measure of protection is to only lock down the system itself. If a user can login to the system, then they have full access to all of the records stored on the system. For smaller companies, this method of securing data can be sufficient. Managers can typically see into their direct reports data. As soon as the company grows to the point of specialization among team members or competition among members of the sales force, this method of securing data is no longer enough.
The next evolution in data security is known as personal lists. There is typically one list per user and potentially one global list. If a user would like to grant access to someone to work with them on one of his/her records, the user needs to grant access to the entire list of records of the user. This method works well for simple situations where the user would like to have an assistant work with the records but not other users and individuals. However, this technique does not work well for complicated teams and/or overlapping teams. Like the previous method, it also does not secure any data from people that are granted some access to records.
Another solution to the problem is to have security lists that are created on a per item basis. Thus, the list on each item will tell the user who has access to the item. While this mechanism allows for good security and good sharing of items, it is typically very expensive to implement and maintain. For example, users have to worry about who has access to the data and will have to make changes to specific items one at a time. Furthermore, system-wide team changes can be very expensive. In addition, the changing of an item's ownership from one team to another is a very expensive operation that requires removing all existing team members and adding new ones. The data structures to maintain all of these teams and records and lists for the many teams and maintaining the consistency of the lists are also expensive from both the database and algorithm perspective. While this method provides a very granular level of security control that is very present in the user's mind, it takes a lot of manual work to maintain in typical installations, and is expensive to maintain and implement in the database layer.
Another simple security mechanism is to protect access to data based on roles. Users with a certain role can see and/or modify certain types of data. For instance, users with the sales role have the ability to see and edit all sales deals while users with the sales audit role can see all deals, but not edit them. This is a relatively crude security mechanism in that it does not easily provide granular access to data. Thus, it is desirable to provide a new more effective and efficient row level security algorithm, and it is to this end that the present invention is directed.